[レポート]PUBG’s architecture (with focus on back end infra) on AWS #AmazonGameTech #AmznGameTechJP

PUBG’s architecture (with focus on back end infra) on AWS

2019年11月20日（水）にアマゾン目黒オフィスでアマゾンウェブサービス社の自社イベント「Amazon Game Developers Conference」が開催されました。

• Amazon Game Developers Conference

本記事は、セッション「PUBG’s architecture (with focus on back end infra) on AWS」をレポートします。

スピーカー

PUBG Corporation DevOps Engineer Kim JungHun 氏

セッション概要

PUBG Corporationは、世界で50万本以上販売されている PLAYERUNKNOWN'S BATTLEGROUNDS の開発および運営をしています。PUBG は Amazon EC2、DynamoDB、SQS、S3 および CloudFront など Amazon Web Services で提供されるさまざまなサービスを利用しています。本セッションでは、PUBG の バックエンドアーキテクチャと、AWS のサービスが実際にどのように利用されているかを紹介します。

レポート

PUBG とは？

5000万枚の売り上げ

300万人の同時接続 ７つのギネス記録

PUBG Architecture Overview

トップタイトル(OutGameと読んでいる) →マッチメーキング →キャラ変更 →戦績の確認

→Angular / MicroService Server .NET Core 3.0(C#)

Donkatsu Dinner を食べるために頑張るバトルロイヤルゲーム

Unreal Engineを利用している

メインシャードとゲームシャードで分けている

メインシャード: WebSocketでクライアントと通信、全てのインスタンスがPrivaet Subnetでバージニアリージョンに置いている

ゲームシャード: UDPで通信、全てのインスタンスがPublic Subnetでバージニアリージョンに置いていて、DBなどは使っていない

メインシャードは一つのリージョン

ゲームシャードは様々なリージョンで作成、地域ごとに存在

データ管理のメインシャードは一つのリージョンで保存している。

メインシャードはPrivate Subnetで、外部からアクセスする場合はPublic Subnet経由

メインシャードでデータを保管

Server Components In Depth

Micro Service構造になっている。

Micro Service長所

• サービスの必要な部分だけスケーリング

• サービスを独立して開発できる

• 障害が発生しても切り分けしやすい

Micro Service短所

• サービスディスカバリー機能が必要

• 運営とモニタリングに手間がかかる

• PUBGは長所が短所より大きいため、Micro Serviceを選択。

マイクロサービスのサービス依存度がよくわからなくなる

"One project, One binary"から"do different depending on settings"

PUBGでは44のマイクロサービスで動いている。

SQS

サービス同士の通信には、一般的なHTTPとMessaging Queueを利用している。

Direct HTTP Request 重複処理 / 失敗しても大丈夫な物に利用

絶対に処理しないといけない物、非同期に処理するものにQueueを利用

キューを利用すると、マイクロサービスの結合度を下げれる

PUBGのBeta環境では様々なMessage Queue Serviceを使っていたが、最終的にSQSを利用した

→無限のキャパシティー、安定、明示的にメッセージを削除しないとキューに残るから、障害が発生してもキューに残り続ける

DynamoDB

オブジェクトリレーションマッピングが必要じゃないので、DynamoDBを利用。

ユーザーのIDを利用して必要なドキュメントを読んで処理している。

NoSQLの中でもDynamoDBを使った理由

• フルマネージドでスケーリングしてくれる、費用の節約

• 瞬間的なバーストを障害なく処理できる

CloudFront

S3をOriginにしてCloudFront可能。

OutGame Sererと連結された時もアップデートでWebSocketが対応し、CloudFrontを利用できるように

CloudFrontとGlobal Acceleratorも出たが、全時間帯で安定的なレイテンシーの方が重要なので、CloudFrontを利用。

Logging Infra

System Game LogとOutGameLogはKinesisに流してElasticsearchと、Kafka LogStreamに投げて、KafkaでE Suports 用のリアルタイム分析

S3のログ分析はData Tech TeamがAirflow + Spark (/Dynamo)で

Monitoring

Server Metrics: DataDog, Promotheusを利用して収集

SystemLogs: Elasticdearch, Kibana

Kubernetes Migration

メインシャードをKubernetesに切り替え

これまではコミット後自動でJenkinsでビルド、S3とECRにアップロード。 CodeDeployでECS/EC2に配布していた。

初期はCodeDeployでデプロイしていたが、合計で100プロジェクトになってしまった。

TerraformとCodeDeployでは多すぎで管理できなくなった。

テストインフラの設定も必要で、サービスされるプラットフォームも増え、必要なテストインフラも必要になった。

テストサーバーもインフラが複雑で管理が難しい。

サービスが増えるにつれて作業量も比例して増えた。

→KubernetesにMigrationした。

Terraformなどでは人が手動で触ったリソースを管理してくれないが、Kubernetesは手動で触っても自動で管理してくれる

明示的な配信管理が可能になり、環境のコピーも容易に。

コンテナの隔離された環境とリカバリー機能で障害の対処に役にたった

デプロイの流れ

Repository -> Jenkins -> ECR -> YAML -> EKS

合計で13クラスターを運用

8クラスターは本番、3クラスターはQAテスト環境(10~30のテスト環境)、2クラスターは内部管理用

EKS: マネージドで管理でき、IAMとの結合が便利

Kubernetesは全ての問題を解決する魔法の杖ではない(学ばないといけないことがたくさん)

• YAML作成方法

• 動作の理解

• 相互作用するアプリケーションの理解

などなど..

Kubernetesに致命的とも言えるバグもあったりした

→大規模なクラスターしか影響が起きないバグなども

"Kubernetes is hard, and not a silver bullet"

明らかに長所があって、分かって使うなら強力なツール

QA

Q. Fargateを使うことは考えなかった？

A. タスクの作成コストがKubernetesと同じくらいで、あんまりメリットがない

Q. EKSを活用する際社員の学習コストは辛くなかったか？

A. 教育プロセスを通過できるようにする制度を作っていきたいけど、難しい

Q. Fifo Queueを使ってるのか？

A. FifoQueueを使っていない。スタンダードQueueを使っている。内部で重複しないようにしている

まとめ

44もの大規模なサービスが動いて正直驚きました。

大規模なアーキテクチャの話が聞けてとても面白かったです！！